Two real problems in `src/system/platform.ts` flagged during the
19.7 audit:

1. Modern iPads (iPadOS 13+, since Sept 2019) ship Safari with the
   desktop Mac UA — no `iPad` token in the user-agent string. The
   `/iPhone|iPad|iPod/i` test missed every iPad sold in the last
   ~7 years, and they fell through `isMobile` as desktop. Confirmed
   observable: `keyboard.ts`, `application.ts`, `header.ts` all
   branch on `isMobile`.

2. Dead-platform UA regexes (`wp`, `BlackBerry`, `Kindle`, `android2`)
   tested for hardware that was EOL'd between 2012 and 2017, burning
   regex cycles on every page load.

## Changes

**iPad detection**: layer a feature check on top of the UA regex —
`navigator.platform === "MacIntel"` plus `maxTouchPoints > 1`. The
`"MacIntel"` string is Apple's frozen legacy identifier (same trick
as `Win32` on 64-bit Windows) that persists on Apple Silicon Macs
*and* iPads in desktop-Safari mode — it's not a CPU check. `Macs
don't have touchscreens; iPads do`, so `maxTouchPoints > 1`
uniquely separates them.

Every existing internal consumer of `isMobile` inherits the fix
transparently.

**Deprecate dead exports**: `@deprecated` JSDoc on `wp`, `BlackBerry`,
`Kindle`, `android2`. Exports stay functional through 19.x for
backwards compat (any external consumer keeps working); IDE warnings
surface at the call sites. Removal scheduled for 20.x.

Also dropped these from `isMobile`'s OR chain. The remaining
`/Mobi/.test(ua) || iOS || android` covers ~99.9% of 2026 mobile
traffic per MDN's recommendation.

**Won't add `isTouch`** as the original issue suggested — we already
have `device.touch` at `system/device.js:116` (feature-detected via
`navigator.maxTouchPoints` / pointer events). CHANGELOG migration
note points there for new code.

## Tests

Six new cases in `tests/platform.spec.ts` covering the iPad-on-Mac-UA
contract — verify the documented `platform === "MacIntel" &&
maxTouchPoints > 1` check identifies iPads correctly, rejects actual
Macs (no touch), Windows touchscreens, and missing-navigator (SSR).
Existing 20 shape / desktop-defaults assertions kept.

Full suite: 3975 passed / 13 skipped / 0 failed (was 3969 — +6 from
the new tests, no regressions).

## Follow-ups (separate issues worth filing)

- `keyboard.ts:85` `if (!isMobile)` skips key-event listeners. iPads
  with Magic Keyboard (now correctly identified) would stop receiving
  keys. Probably always-attach + let no-op-on-pure-touch sort itself
  out, but needs the iPad-with-keyboard test path to validate.
- Migrate to `navigator.userAgentData` (Client Hints) where available.
  Chromium-only today; Safari/Firefox lag. 20.x candidate.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

`keyboard.ts:85` skipped attaching `keydown` / `keyup` listeners when
`isMobile === true`. The gate assumed "mobile = no physical keyboard"
— invalid in 2026 with iPads (now correctly identified post the
platform fix above) using Magic Keyboard, Bluetooth keyboards on
phones, Samsung DeX, ChromeOS tablet mode, etc.

Two empty listener slots cost essentially nothing on touch-only
devices; the handler's unbound-key path is a single map lookup
that returns undefined.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

`prefer-const` flipped `export let autoFocus = true` → `const` during
the .js → .ts conversion lint pass because nothing in the module
reassigns it. The JSDoc still describes it as user-settable behaviour
("Specify whether to automatically bring the window to the front") —
`let` keeps the door open for an internal setter without forcing
another module-shape change.

Behaviourally moot today: ESM namespace-import bindings
(`device.autoFocus = false` via `import * as device`) are read-only
regardless of `let` / `const`, so external mutation never worked
either way. But intent matters.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot review batch from the platform.ts and device.ts review rounds:

- platform.ts header doc: add missing space before \`true\` for
  BlackBerry / Kindle entries (rendered as malformed markdown
  otherwise).
- platform.ts @deprecated: prepend `since 19.7.0 — ` to wp /
  BlackBerry / Kindle / android2 to match the codebase's existing
  convention (matches video.js, renderable.js, entity.js style).
- platform.ts isMobile: drop redundant `|| false` from the OR chain
  (every operand is already a boolean).
- tests/platform.spec.ts: rename "Mac touch-bar laptop" test —
  Touch Bar isn't a touchscreen and doesn't report maxTouchPoints.
  The test is about the `maxTouchPoints === 1` edge case directly.
- device.ts isMobile JSDoc: drop the dead-platform list (BlackBerry,
  Windows Phone, Kindle) — they're no longer in the isMobile OR
  chain per the upstream platform.ts change.
- device.ts getElement JSDoc: drop "or null if not existing" — the
  function falls back to `document.body` and never returns null.
- device.ts domRect cache: revert `new DOMRect(...)` → plain object
  literal so module load doesn't ReferenceError in Node / SSR
  environments where the DOMRect constructor isn't defined. The
  literal is cast to `DOMRect` at the return site.
- CHANGELOG: rephrase the `system/device` conversion entry to make
  the rename explicit ("renamed from device.js → device.ts" rather
  than referring readers to a path that no longer exists), and drop
  the (now-reverted) DOMRect claim.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…cation (#1467)

Fullscreen control finally has app-instance context. The canonical
path is now `app.requestFullscreen()` / `app.exitFullscreen()`,
defaulting to the app's `parentElement` (canvas + sibling HUD go
fullscreen together) and accepting an optional Element override.

The static `device.requestFullscreen()` / `device.exitFullscreen()`
helpers stay for backwards compat (still work through the deprecated
`getParent()` → `game.getParentElement()` global-game lookup), but
are now flagged `@deprecated since 19.7.0` pointing at the
Application methods.

Updates the two examples that wire `F` → toggle fullscreen
(platformer + platformer-matter) to use the new app-instance API.
Each `createGame.ts` calls `_app.requestFullscreen()` directly; each
HUD calls `game.requestFullscreen()` since the HUD code path doesn't
have an `_app` reference and `game` is already imported.

Implementation note: the new Application methods skip the
vendor-prefixed `webkitRequestFullscreen` / `mozRequestFullScreen`
probing the device wrappers do — every modern browser has unprefixed
`Element.requestFullscreen` since ~2018. Users on ancient browsers
that still need the prefix dance can fall back to the deprecated
`device.requestFullscreen()` path which preserves the legacy probing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…#1467)

`device.isFullscreen()` doesn't need Application context: the browser
tracks exactly one fullscreen element per document regardless of how
many Applications are running. Unlike `requestFullscreen` (needs to
know WHICH element) and `exitFullscreen` (paired with request),
`isFullscreen` is a stateless probe.

Drops:
- `@deprecated` JSDoc from `device.isFullscreen` + clarifies it's a
  document-state probe.
- the eslint-disable comments inside `device.requestFullscreen` /
  `device.exitFullscreen` that were silencing the now-non-deprecated
  internal call.
- the eslint-disable comment inside `Application#isFullscreen` for
  the same reason. The method now reads as a clean thin convenience
  wrapper.

`Application#isFullscreen` stays as a convenience so the trio reads
together (`isFullscreen` / `requestFullscreen` / `exitFullscreen`)
on the app instance, but its JSDoc now correctly identifies
`device.isFullscreen` as the canonical probe rather than implying
the device version is being phased out.

CHANGELOG updated to reflect the corrected scope of the deprecation
(request + exit only; isFullscreen stays).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Uses the new `app.requestFullscreen()` / `app.isFullscreen()` /
`app.exitFullscreen()` trio so the showcase exercises the canonical
post-19.7 API. No HUD button — just the keyboard shortcut, matching
the rest of AfterBurner's minimal-chrome aesthetic.

Handler is registered + torn down inside `createGame`, so the
example's React mount/unmount cycle doesn't leak duplicate listeners
across remounts (which would stack up fullscreen toggles on every
key press).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two related fixes:

1. **F-key handler moved inside the preload callback.** Registered
   at createGame's sync tail it was getting stripped on the first
   React StrictMode dev unmount (utils.tsx runs teardown on every
   useEffect cleanup) and never re-registered because the canvas-
   remount path doesn't re-invoke createGame. Registering inside
   the preload callback puts it alongside the rest of the game-
   running state, surviving StrictMode the same way `audio.playTrack`
   does. Matches the platformer / platformer-matter pattern.

2. **HUD positions read live viewport dimensions.** `HUD.ts`
   hardcoded `CANVAS_W=1024 / CANVAS_H=768`; after the recent
   1024×576 retune the GAME OVER overlay landed in the lower
   half (y=372 in a 576-tall world) and the bottom-edge credits
   ran off-canvas entirely (y=752). Now the constructor reads
   `app.viewport.width / .height` once and uses those everywhere
   (score, hi-score, lives, music + asset credits, GAME OVER
   + sub-line, DeathFlash bounds). The screen-projection ortho
   that drives `floating = true` renderables uses the same
   `viewport.width / .height` (see `Camera3d.screenProjection`),
   so the HUD positions track whatever Application size the
   example is configured with — no resize listener needed
   under `scale: "auto"` (default scaleMethod doesn't call
   `renderer.resize`).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot flagged the public export as adding a forever-supported API
surface just for the spec's benefit. The function stays exported (the
spec asserts the SAME predicate the module evaluates at load time —
no drift), but the JSDoc now declares it as a test-seam with no
stability guarantee. TypeDoc with `--excludeInternal` hides it from
the generated docs; consumers reaching for it accept that the engine
can change / inline / rename it without a breaking-change bump.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CI's `pnpm lint` flagged the missing `@param nav` on the function
I added in the previous commit. Local `pnpm build` ran clean but
hits a different code path (build step has stricter JSDoc enforcement
than the standalone `eslint src tests` invocation CI runs).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot caught a real asymmetry: `requestFullscreen` got the
four-variant OR chain (`requestFullscreen || webkit… || moz… ||
ms…`) on both `Application` and the deprecated `device` wrapper,
but `exitFullscreen` just called `document.exitFullscreen()`
unconditionally on both. If `hasFullscreenSupport` was set via a
prefixed `*FullscreenEnabled` flag (older WebKit on iOS, older Safari,
IE-derived browsers), the unprefixed `document.exitFullscreen` may not
exist and the call would throw — exactly the failure mode `app.
requestFullscreen` was already protected against.

Both `app.exitFullscreen` and the deprecated `device.exitFullscreen`
now mirror the request side: probe `exitFullscreen ||
webkitExitFullscreen || mozCancelFullScreen || msExitFullscreen` (note
the Mozilla quirk — `mozCancelFullScreen`, not `mozExitFullScreen`),
guard the Promise return with `result instanceof Promise` so
vendor-prefixed variants returning `void` don't trip the `.catch`.

`DocumentLegacy` in `device.ts` and a new local
`DocumentWithLegacyExitFullscreen` in `application.ts` carry the
intersection-type declarations the four-variant probe needs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…om device.* (#1467)

Two tweaks in response to PR feedback:

1. **Circular import broken** (Copilot review on fbf04aa).
   `lang/deprecated.js` was importing `hasFullscreenSupport` /
   `isFullscreen` from `device.ts` while `device.ts` re-exported
   `requestFullscreen` / `exitFullscreen` from `lang/deprecated.js`.
   Factored both probes into a new leaf-level `system/fullscreen.ts`
   that owns the four-variant `DocumentLegacy` type and the
   detection logic; `device.ts` and `lang/deprecated.js` both import
   from there, eliminating the cycle.

2. **Dropped the `me.device.requestFullscreen` / `me.device.exit
   Fullscreen` aliases entirely.** `index.ts` already does
   `export * from "./lang/deprecated.js"`, so the two function names
   surface at the top level as `me.requestFullscreen()` /
   `me.exitFullscreen()` — a deprecated shim with runtime warning
   that points at `Application#requestFullscreen` /
   `Application#exitFullscreen`. Re-exporting them under
   `me.device.*` defeated the whole point of "they live in
   deprecated.js" — it leaked the deprecated names back into the
   namespace they were moved out of. Users still calling
   `me.device.requestFullscreen()` directly need to either migrate
   to `app.requestFullscreen()` (canonical) or drop the `.device.`
   segment.

`device.ts` keeps `hasFullscreenSupport` and `isFullscreen` exposed
under `me.device.*` via the new re-export from `system/fullscreen.ts`
— those are non-deprecated probes and remain valid public API.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…types

Copilot caught that `tsconfig.build.json` doesn't set `stripInternal`,
so the `@internal` JSDoc on `isIPadOnMacUA` doesn't actually prevent
the emitted `.d.ts` from carrying the function (and its parameter
type) into the public surface. The named `NavigatorLike` alias would
have shown up in the published types as a brand-new engine-defined
type — making any later rename / removal a breaking change.

Inlined the navigator shape as
`Partial<Pick<Navigator, "platform" | "maxTouchPoints">> | undefined`
so only DOM-lib types appear in the signature. The `@internal` tag
still flags the predicate as test-seam-only for TypeDoc (`--exclude
Internal`), and the contract under test is unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>